openarenafandomcom-20200216-history
Mapping manual/Creating dynamic features
With the explanation of how each of the trigger/func entities work, now it's time to practice how to add hazards and features to our level. Assigning entities to brushes This is a basic step, as every feature in this page and many others use this procedure when working with brush-based entities such as func_* or trigger_*. * Create the brushes you're going to use for your entity. ** If you're going to use a trigger_ entity, only one brush texturized in all of its faces with the common/trigger texture is needed. ** If you're going to use a func_ entity, you can use one or many brushes. They don't need a specific texture. * Select the brush(es) you want to assign the entity. * In any of the 2D views, click the right mouse button and select the adequate entity. Alternatively, open the "Entities" windows (usually "n" key) and select one from the list. Teleporters Teleporters allow the players to exit from one area and enter to another in a blink. For example, the dual teleporters in am_galmevish2. * Create the surrounding brushes or add the related model. * Create a brush texturized in all of its faces with the common/trigger texture. Place it where the players should be teleported. * Assign the trigger_teleport entity to the common/trigger'd brush. * Place a misc_teleporter_dest in the floor of the destination area.In case you notice you sometimes "get squished" at the moment of teleporting (not "telefragged" by some other player, but you randomly die for no apparent reason), try placing the misc_teleporter_dest rised above the ground, something like 16 units away from brushes. * Select the trigger_teleport brush and then the misc_teleporter_dest entity and connect them. Considerations * When you give multiple targets the same target name, the teleporter will randomly select from one each time it is used. * Be careful while placing a teleporter destination: when exiting from a teleporter, players get a small push forward... if re-appearing too near to the edge of a platform, players may fall down from it. * In case player "A" is in the place where player "B" appears when exiting from a teleporter, player "A" will be killed ("telefragged"). You may consider this while placing the teleporter exit. * Teleporters do "fuse" starting and destination bot clusters into one. You should consider this, while placing cluster portals to optimize bot play performances. Mirrors Another cool effect which can be created is that of a mirror.GTKR Manual, Appendix D Some maps such as Q3's q3dm1 (Introduction) uses this technique. * Apply common/mirror texture to a brush (not a patch). * Place a misc_portal_surface entity within 64 units of the mirror and at roughly eye level for the character. Because a mirror shows all that it can "see" the mapmaker needs to take special care that his mirror doesn't see so much of the map that it affects game performance. Considerations * A mirror should not be able to see another mirror or portal surface. This means no mirror mazes or mirror facing each other to produce infinite reflections. Portal teleporters Also known as gates, they are special kinds of teleporters which also lets players see the other side of the map place to where they're teleporting. There're two examples in the oa_dm5 map. It's an easy process, but it can be difficult in some parts. * Create a brush texturized with sfx/portal_sfx in one face, and common/nodraw in the other faces. * Place immediately next to the portal_sfx face an entity misc_portal_surface. You should separate the brush from the entity no more than 32 or 64 px. * Create a teleporter trigger with the same size than the previous brush. * In the destination area, place a misc_portal_camera. * Connect the misc_portal_surface and the misc_portal_camera. * Place a target_position where you want the camera to watch. * Connect the misc_portal_camera with the target_position. * Save your map and test the portal ingame. Considerations * Portal teleporters are less common than "standard" teleporters also due to the fact that gates, like mirrors, stresses the engine, due to the potentially huge number of extra polygons to compute. A workaround for this problem is to create standard teleporters and place drawings, symbols or screenshots textures there, to help identifying the place where the player will reappear. Of course, it cannot mimic properly a gate, due to the fact it does not allow the cool effect of viewing other players fighting through the portal. Jumppads and launchpads These two features differ in that a Jumppad launches vertically a player stepping on it, while the launchpad does this horizontally. There's also a hybrid of them, a jumppad with launchpad properties which launches the players diagonally. The process to create both three of them, however, is the same. Examples of jumppads can be found in am_spacecont (two near the higher pillar) and am_underworks2 (at the depot room); while launchpads can be found at hydronex2 (central area); and the hybrid can be found at am_underworks2 (generator room). * Create the brushes which will act as the jumppad/launchpad/hybrid. * Create a brush covering the top face of the *pad textured with common/trigger in all of its faces. * Assign the trigger_push entity to the common/trigger'd brush. * Add a target_position entity at the highest point of the jump/launch. * Select the trigger_push brush and the target_position entity, and connect them. * Test and refine until it launches at the desired height/distance. Take in account the result may vary, with different game physics settings: maps should be tested with "fixed 90 Hz", "fixed 125 Hz" and "Accurate" physics, and should play well in all three of them. Considerations * For launchpads, the center point of the target must be higher than the center point of the trigger_push. * trigger_push automatically makes the bouncepad sound. * Speed of travel is determined by the distance needed to reach the target entity. Longer = faster. * As mentioned in the bot play page, the trigger_push and target_position trajectory must not cross clusterportals. Wind tunnels A wind tunnel launches a player to a selected area. Two examples of the feature are located in the map oa_dm7, each at an extreme of the map. One of them is located at the back of the map, and launches the players to the top of the central tower, while the other brings the players to the immediately upper walkways. * Create the tunnel. * Fill each straight path of the tunnel with a brush textured with common/trigger in all of its faces. These brushes shouldn't overlap nor touch themselves, for clean mapping reasons. * Assign each of these trigger brushes a trigger_push entity. Remember that each trigger should only cover one brush. * Add at the end of every straight path a target_position entity. Locate them at the begining of the immediately next trigger brush. * Connect the trigger_push brush with the immediately next target_position in a way that trigger_push1 connects with target_position1, trigger_push2 connects with target_position2 and so on. Only one trigger_push to only one target_position. * Test and refine until the tunnel behaves correctly. Liquid pits These pits are environmental features with different uses sharing the same easy procedure. Water pits don't damage the player at first, but if players spend too much time in this pit, they start losing health until they die from drowning or exit the pit in order to take a breath. Slime and lava pits have the same properties as Water, but players take medium or heavy damage just from touching them. The Battle Suit item prevents the players from getting hurt in these pits, so they can be useful for holding powerful items (such as the BFG in am_lavaarena and am_lavactfxl), requiring the players to think a bit on how to reach them. * Create the pit. * Fill it as much as you wish with a brush texturized in all of its faces with a liquid texture. * In lava/slime pits, create a brush covering the bottom half of the previously created brush, texturized with common/nodrop in all of its faces. Don't assign it any entity. This ensures that no item, weapon or objective is dropped onto the void, as it causes trouble with botplay. Death pits Unlike lava, water and slime pits, the death pits will kill players even if they're using the Battle Suit item. It also needs some more stuff in order for it to work properly. There are many examples of this feature, and practically every space map uses it. * Create the pit or space map. * Create a brush covering the bottom half of the pit/void texturized with common/trigger in all of its faces. Assign it the trigger_hurt entity, set the key "dmg" with the value "9999" and enable the spawnflags "SILENT" and "NO_PROTECTION". This will kill any player touching it.Suggested practices for CTF mapping by Threewave * Create a brush covering the bottom half of the previously created brush, texturized with common/nodrop in all of its faces. Don't assign it any entity. This ensures that no item, weapon or objective is dropped onto the void, as it causes trouble with botplay. * Create a brush 1.5x the size of the first trigger brush, texturized with common/trigger in all of its faces, and assign it the trigger_multiple entity. * Create a target_remove_powerups entity. This removes any powerups and runes the player may hold. This doesn't remove holdables, health, armor or weapons. * Create a brush covering the top half of the first trigger brush, texturized with common/trigger in all of its faces, and assign it the trigger_multiple entity. * Create a target_speaker entity, and set the key "noise" with the value "*falling1.wav". This causes the falling scream as the players fall to their doom. * Connect the trigger_multiple brush with the target_speaker entity. * If you're not creating a space map, you can add an additional brush texturized in all of its faces with a fog texture, covering the whole pit or its bottom part, obtaining the so-called "fog of death". Considerations * A trigger_hurt always starts on in the game, unless start_off spawnflag is set. * In grapple-based gametypes it's possible for people using the grapple to take advantage of the space between the top of the hazard and the and the trigger_hurt at the bottom which should kill them. Also, by grappling they could repeatedly play the falling.wav sound and disrupt play on the server. Because of this, a third brush must be created, covering almost the whole pit/void texturized with common/trigger in all of its faces. Assign it the trigger_hurt entity, set the key "dmg" with the value "10" and enable the spawnflags "SLOW" and "NO_PROTECTION". Doors Doors can be single or multiple brushes, they can open in one direction, or brushes can move in different directions.LevelDK mapping tutorial, Appendix * Create the brushes that you intend to convert into a func_door. * Assign them the func_door entity. * Summon the entity editing window and set an angle for the door to open. * Optionally, you can set the speed for the door, the amount of damage a door takes before it is triggered open, or whether or not it acts as a crusher and inflicts damage. Considerations * If you want doors to operate together, you have to team them manually by assigning the same team name to all of them. Setting wait =-1 for normal touch doors makes them work erratically. Use this only for damage-only ("health" key set to non-zero value) or targeted doors. * If you want the doors to open in opposite directions away from each other, they must be separate door entities but teamed together. * In some cases it is useful to cull what is drawn behind a door in order to control vis. This is never a perfect solution for multiplayer games, as the map can lag as the doors open and tris climbs steeply. In order to cull behind a door, or set of doors, an areaportal is placed inside the door entity. Draw a thin brush (8 units thick) made of skip, that completely fills the area filled by the door. Texture one side of the brush with the common/areaportal texture. The areaportal will only work if each area of the map is completely sealed off from the next area with areaportals. As the doors open and close the areaportal brush is triggered and the far side of the func_door entity is culled. Rising platforms Platforms can be triggered by another entity (as a button), or will work automatically when a player steps aboard. Examples of this platform can be found in the map kaos2, connecting the lower floor with the upper one. Also, czest1dm uses his in order to keep the Railgun to be abused. * Create the brushes you intend to create the entity from. * Assign them the func_plat entity. * Edit the entity's properties. Platforms are drawn in the editor in the highest, raised position, but spawn in game at the lower point. A slow rising platform can be used to reach more powerful items quite effectively. Adjust the height key value so that the platform sits neatly on the floor in its lowest position. Considerations * By default, the total amount of vertical travel of a platform is implicitly determined by the overall vertical size of the brushes of which it's made minus the lip value. But if the "height" key is used, then the total amount of vertical travel of the plat will be exactly that value regardless of the shape and size of the plat and regardless of the value of the "lip" key. Using the "height" key is the best method for any kind of platforms and the only possible one for thin plats which need to travel vertical distances many times their own thickness. * The most significant problem with func_plat entities is the absence of sounds. To this end, replacement sounds must always be included with any map which uses this entity. * Bots can be rather stupid about running underneath platforms. This can be easily avoided by including as part of the entity a player or bot clip brush that at the platform's highest point completely fills the space below to the ground. * Clip brushes can be used to create the additional size for "thin" platforms. The id designers recommend using plats with care and that plats be built as "solid" pillar-like lifts. Bobbing platforms/decorations Platform which oscillates back and forth in a linear motion. By default, it has an amount of displacement in either direction equal to the dimension of the brush in the axis in which it's bobbing. Entity bobs on the Z axis (up-down) by default and crushes the players if they're blocking it.GTKR Manual, Appendix B2 * Once again, create and select the brush or brushes you want to create the entity from. * This time assign them the func_bobbing entity. * Adjust the properties in the editing window. Considerations * In order for the sound to be emitted from the location of the entity, it is recommended to include a brush with an origin shader at its center, otherwise the sound will not follow the entity as it moves. The movement of the func_bobbing follows a sinoid wave pattern. Rotating platforms/decorations The common/origin texture is used to specify the centre of the entity, around which it rotates along an axis set in the entity editing window. Entities must be created from at least one solid brush, so when using a model you must also use a small player clip brush as part of the entity. An example of this is the rotating fan in pxlfan. * Draw out a small brush out of common/origin, and a small playerclip brush. * Select both and drop the entity menu, select func, then func_rotating. * Edit the properties as required. * In order to use a model as an entity, select both the model and the newly created func_rotating, and connect them. Considerations * You should always target the model at the entity or a strange bug may occur where the model does not get baked into the .bsp on compile as normal. * You need to have an origin brush as part of this entity. The center of that brush will be the point through which the rotation axis passes. Setting the origin key is simply an alternate method to using an origin brush. It will rotate along the Z axis by default. You can check either the X_AXIS or Y_AXIS box to change that. Killing pendulums It's a set of brushes rendered in-game as a back-and-forth swinging pendulum which kills anybody on its path. * Create the pendulum itself with brushes. * At the top of this pendulum, create a small brush with the common/origin texture. * Assign the func_pendulum entity to these brushes (including the origin) * Place the pendulum where it should go. Considerations * You need to have an origin brush as part of this entity. The center of that brush will be the point through which the rotation axis passes. Pendulum will rotate along the X axis by default. Pendulum cannot rotate along Z axis. The speed of swing is not adjustable, and the "dmg" key has no effect. Shooters A shooter fires a single munition of grenade/plasma/rocket (depending on the shooter type) when being triggered. These shooters can be used to damage the players after they get an important item, such as in the Q3 map q3dm11, Deva Station. Some examples of shooters can be found in the map oa_bases3plus3. Activated by a button * Create a button with brushes. Assign it the func_button entity and adapt it to your needs. * Create a hole where the shooter will be placed. * Add a shooter_grenade/shooter_plasma/shooter_rocket entity in this hole. * Connect the func_button with the shooter. Activated by a trigger * Create a brush texturized in all of its faces with common/texture. * Assign it the trigger_multiple entity. * Create a hole where the shooter will be placed. * Add a shooter_grenade/shooter_plasma/shooter_rocket entity in this hole. * Connect the trigger_multiple with the shooter. Considerations * When the random key is set, its value is used to calculate a maximum angle deviation from the normal trajectory formed by a straight line between the shooter and the aiming entity it targets. The final trajectory will be a random value anywhere between no deviation at all (0) to maximum deviation (value of the random key). * Both the setting "angles" key or "targeting a target_position" methods can be used to aim the shooter. However, the target_position method is simpler. * If you want a shooter to fire multiple times, target the activator on two or more target_delays. Set the delay time to a different value for each (if using a trigger multiple, the WAIT value on the trigger should be greater than the longest delay on the target_delay). Target each target_delay on the shooter. "Trains" This is perhaps the least often used of all the entities available in OpenArena. It allows to make something move along an arbitrary path, but has got major limitations. * Create a path for the train by using the path_corner entities. Connect them so the "train" can use them asits "rails". * Create the brushes of the "train", with a small common/origin brush in the center. * Assign this group of brushes the func_train entity. * Connect the func_train with the first path_corner entity. The train will spawn in game at the path_corner that it was targeted at. Considerations * Trains always start on in the game. * Trains do not damage the player when blocked a trigger_hurt is attached to it. <<-- HOW to attach a trigger_hurt to a func_train??? * Trains cannot emit sound. * Trains are not triggerable or toggle-able. * Trains cannot be block-stopped just by getting in their way, the player must be wedged between the train and another obstacle to block it. A train will push a character until he will be blocked by a solid object or another character: then the train will be blocked, with an odd "shaking" effect. * Setting the wait key to -1 in the path_corner entities will not make the train stop on the path corner, it will simply default to 0. * The center of the origin brush in the func_train follows the path. Location names It's a good idea to add location names to every map you create, especially if it is mainly meant for team-based gametypes. Examples of location names could be like "blue base", "red armor", "bridge", "central square", "teleporter room", "quad room", etc. * Insert a target_location entity. * Set the message key to the name of the area (eg: "railgun", "depot", "generator"), possibly shorter than 16 characters. Considerations * The target locations are "PVS-dependant". If a PVS can "see" it, then that location message is displayed. Be conservative in placing location markers. Because of the way the location code is implemented, it causes a large amount of data to be transmitted regularly. * Place the target locations in such a way that the entity can be "seen" from most, if not all, the positions that a player can stand in when it is inside that area. Fewer are better, even if it means that occasionally, a team mate is in an unknown location. * Turn on team overlay table, load your map in any team-based gametype, then roam to test your location names work as expected. * If necessary, you can type the same "message" in more target_location entities. "Count" key can be used to specify text color (see Mapping_manual/Triggers and movers#target location). Print a message on the screen You might have found a secret in Q3, in the map q3dm11, "Deva Station", where you find Commander Keen's Dopefish and a message telling you that you have found a secret. This is easy to doWorldspawn Archive's Printing text on screen: * Create the trigger. It can be a trigger_multiple, a button, whatever. * Add a target_print to the level. * Modify the value of the "message" key so it can show the message you want. * Activate the PRIVATE spawnflag. This caues that only the player who activated the trigger receives the message. * Connect the trigger/func entity and the target_print. Give items to players (at spawn time) Also, you might want the players to spawn with a certain item/weapon or group of them. That's also easy to do, and many OA maps implement it (such as oa_koth1 which gives the players a Shotgun).Worldspawn Archive's Giving an item to a player This can also be used to create a "Rocket Arena"-style map, where everyone starts with all the weapons. The given items aren't seen in the map.GTKR Manual, Appendix B7 * Create the player spawnpoints you want to give items to. * Create a hollowed cube somewhere outside of the map. * Place the items you want to give to the players inside of this cube. * Add a target_give entity in this hollowed cube. * Select one spawnpoint, then the target_give, and connect them. Repeat this step for every spawnpoint you want to give items to. * Select the target_give, then the item to be given, and connect them. Repeat this step for every item you want to give. Give items to players (when in a certain place) And finally, you might want to recreate the health/armor giving column you have seen in Q3's q3dm10, isn't it? The one which gave the players armor and health in bunches while they stepped onto it. Here's the procedure: * Create the item giving tube/pool/whatever. * Surround it with a trigger_multiple-texturized brush. Give it a "wait" time of 0.5 (of course you can adjust this according to your needs). * Create a hollowed cube somewhere outside of the map. * Place the items you want to give to the players inside of this cube. * Add a target_give entity in this hollowed cube. * Select the trigger, then the target_give, and connect them. * Select the target_give, then the item to be given, and connect them. Repeat this step for every item you want to give. Considerations * When the random key is set in the trigger_multiple, its value is used to calculate a minimum and a maximum delay. The final time delay will be a random value anywhere between the minimum and maximum values: (min delay = wait - random) (max delay = wait + random). Notes External links * TramDesign explanation and more detailed how-to * WeMakeMaps.com tutorial